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of  the  Department  of  the  Defense  or  any 
d  e  p  a  r  t  me  n  t  thereof, 


ABSTRACT 

The  concepts  and  status  of  the  HULSTRX  development  along  with  a  discussion 
of  its  utility  in  the  rapidly  changing  U ,  S ,  Navy  ship  design  e  n  v  i  r  o  n  me  n  t 
are  presented,  HULSTRX  provides  for  definition  of  ship  structure  at  pre¬ 
liminary  and  contract  design  levels  in  t  e  r  ms  of  absolute  g  e  o  me  t  r  i  c  data 
and  relational  component  data,  Relational  structural  component  defini¬ 
tions  allow  for  quick  design  changes,  and  absolute  geometric  description 
of  the  hull  surface  can  be  independently  defined,  Application  routines 
will  enable  designers  to  efficiently  produce  design  drawings,  various 
structural  and  geometric  analyses,  and  interface  with  design  or  product 
mo d e I  s  of  other  s y s t  e ms , 


178 


I  REAPS  PAPER  ON  HULSTRX  -  A  U.S.  NAVY  STRUCTURAL  DESIGN  MODEL 


HULSTRX  ■  Present  Status 


The  dual  purpose  of  this  paper  is  to  report  on  the  work  that  has  been 
done  in  adding  the  interactive  Structural  Scantling  File  (SSF)  to  the 
Hull  Stucture  (HULSTRX)  program  and  to  outline  the  work  to  be  done  this 
fall  in  making  the  SSF  an  interactive  design  tool  with  graphics  capabil¬ 
ity.  In  addition,  the  outlook  of  the  U.S.  Navy  on  the  use  of  computer 
aided  design  tools  will  be  reviewed,  and  some  thoughts  will  be  presented 
on  the  major  considerations  of  a  general  data  base  design  of  the  future, 

Several  papers  have  been  presented  on  the  HULSTRX  progress  during  the 
last  few  years,  See  References  2,  3,  and  4,  These  papers  describe  the 
background  for  the  development  of  HULSTRX, 

HULSTRX  was  last  reported  on  in  June  of  this  year  (Reference  4),  The 
addition  of  the  Ship  Structural  File  to  the  HULSTRX  programs  has  given 
the  structural  designer  the  capability  to  interactively  add  structures 

to  the  geometry  of  the  ship,  and  to  have  structural  drawings  produced 
both  on  a  graphics  terminal  as  well  as  on  a  plotter, 

The  workings  of  the  SSF  program  will  be  discussed  a  little  later,  The 

way  in  which  it  and  the  extensions  to  it  interface  with  the  existing 

HULSTRX  files  are  shown  on  Fig,  1,  SSF  is  essentially  a  stand-alone 
program  that  will  create  its  own  interactive  database  in  which  the 
structural  details  are  stored,  These  details  describe  the  structure 
with  respect  to  type,  material  and  extents,  The  traces  on  which  they 
are  to  be  placed  are  described  in  geometrical  terms  on  the  Design  Geome¬ 
try  Library  (DGL)  file  created  by  HULSTRX, 

The  next  step  in  the  direction  of  the  generation  of  drawings  is  to  add 
capabilities  to  the  SSF  Program  so  that  drawings  can  be  generated, 

Such  drawing  will  first  be  displayed  on  a  graphics  screen  and  later  on 

on  a  plotter  or  drafting  machine,  This  effort  is  under  way  and  will  be 

completed  by  the  end  of  the  year,  (Fig,  2)  It  is  recognized  that  HULSTRX 
also  should  be  converted  to  an  interactive  design  tool,  Such  an  effort 
may  be  started  next  year, 

HULSTRX  is  the  structural  portion  of  Computer  Supported  Design  (CSD), 

The  CSD  system  is  a  set  of  linked  individual  computer  programs  which 
assist  the  cognizant  engineer  in  developing  a  ship  design,  The  ship¬ 
building  industry  is  in  a  changing  posture,  The  change  is  not  just 
rhetoric,  but  a  continuing  effort,  The  needs  of  the  industry  should 

cover  the  entire  spectrum  of  ship  design,  construction,  overhaul,  and 
repair,  These  needs  have  been  recognized  for  many  years  but  the  computer 

hardware  and  software,  and  people  that  are  eager  to  make  the  change, 
have  recently  b  e  c  a  me  available  to  the  industry  in  the  n  u  mb  e  r  s  needed  to 

exercise  the  change,  The  me t  h o d  of  design  must  change  and  the  t  i  me 
required  to  complete  a  design  must  be  reduced,  Since  the  use  of  the 
computer  was  accepted  as  a  tool  of  the  industry,  the  way  to  control  it 
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had  been  somewhat  lost,  Manual  methods  allowed  three  (3)  to  eight  (8) 
design  studies  for  a  single  ship  design  to  be  f  i  r  me  d  up,  Wi  t  h  the 
computer,  the  studies  go  into  the  hundreds  and  the  design  process  has 
grown,  not  decreased,  Management  of  a  comput er -  as  si  st ed  design  is  a 
must  if  the  real  value  of  computer  assistance  is  to  be  realized, 

Design  for  design's  sake  should  no  longer  be  tolerated  with  computer- 
assisted  designs,  The  process  must  be  a  continuous  effort  and  build 
from  the  previous  work  done  and  not  start  over  for  each  phase  of  design 

and  construction,  The  ma  n  u  a  I  me  t  h o d  gave  us  little  option,  but  that  has 

changed,  The  ability  to  work  f r om  st r uct ur ed  programs  with  a  data  base 
allows  for  true  standards,  The  control  of  time,  schedule,  cost  and 
quality  can  now  be  logically  accomplished  with  a  systematic  approach, 

The  needs  of  the  industry  should  be  keyed  to  professional  training,  The 
people  presently  studying  engineering  and  even  many  trades  are  exposed 
to  computers  and  the  mystique  of  how  they  work  is  gone,  Home  computers, 

video  g  a  me s ,  and  TV  graphics  have  set  the  tone  of  the  country,  The 

youth  of  the  country  are  ready  for  a  computerized  industrial  base  and 
ship  designers  and  builders  should  be  ready, 

HULSTRX  is  one  of  the  tools  being  developed  to  meet  the  challenge,  The 

system  is  being  built  on  the  strength  of  other  p  r  o  g  r  a  ms  and  the  needs  of 
the  user,  HULSTRX  has  many  requirements;  no  thought  was  given  to  develop 

a  special  stand  alone  system,  HULSTRX  as  presently  defined  is  about 

sixty- five  (65)  percent  complete,  Based  on  the  original  program  plan, 
the  present  status  should  be  ninety  (90)  percent  complete,  This  is  a 

true  indication  of  how  the  needs  of  a  system  grows  as  user's, 

HULSTRX  is  a  relatively  new  program  when  one  considers  the  time  it  takes 

to  develop  a  system  of  this  nature,  The  major  goal  is  to  computerize 

the  process  and  to  develop  computer  graphic  drawings  from  pre  i  mi  nary 

through  contract  design,  In-house  designs  that  are  done  by  the  U.S, 

Navy  without  contractor  support  are  done  with  engineers,  The  Surface 
Ship  Structures  Division  has  only  three  (3)  types  of  people  working  in 
the  office;  engineers,  engi  neer s- i  n- t r ai  ni  ng,  and  engineering  aids, 

The  engineers  are  full  t  i  me  e  mp  I  o  y  e  e  s  that  selected  the  Surface  Ship 
Structures  Division  as  their  main  area  of  employment,  Engineers  -in¬ 
training  are  the  young  engineers  that  are  starting  full  t i  me  careers 
with  the  Navy,  They  spend  four  (4)  weeks  in  each  code  as  part  of  their 

exposure  to  the  various  discipline  in  the  NAVSEA  design  area,  Engineer¬ 

ing  aids  are  students,  usually  with  one  (1)  to  three  (3)  years  college 
that  work  summers  and  long  holidays,  This  limited  description  is  given 
to  show  the  need  for  a  special  system  which  will  be  able  to  carry  a 
larger  workload,  thus  reducing  personnel  needs, 

Most  people  that  work  in  the  design  area  must  realize  that  engineers  do 

not  like  to  draw  drawings  in  the  formal  sense  of  the  word,  They  will 

sketch  structures,  develop  load  d  i  a  g  r  a  ms ,  and  spend  n  u  me  r  o  u  s  hours 
developing  a  finite  element  model  but  that  all  falls  within  the  engineer¬ 
ing  arena, 
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HULSTRX  took  into  account  these  user  constraints  into  account  in  the 

planning  and  development,  The  basic  development  was  the  line  definition 

of  a  shell  expansion;  this  was  selected  as  a  keystone  requirement  and 
when  accomplished  would  allow  for  the  development  of  the  simpler  sur¬ 
faces  such  as  decks  and  bulkheads,  The  next  phase  was  to  develop  the 
scantling  file  that  is  the  subject  of  this  paper  and  will  be  covered  in 

detail  later  on, 

Having  a  c o mp u t e r  drafting  program  as  support,  a  structural  engineer 
should  directly  interface  with  his  engineering  tools,  One  of  the  major 
programs  that  is  used  by  the  Navy  is  the  Structural  Synthesis  Design 
Program  (SSDP),  This  program  desi gns  all  longitudinal  structures  for 
Navy  type  designs  in  the  hull  of  a  ship  based  on  standard  Navy  design 

criteria,  The  output  is  of  a  general  nature  and  requires  interpretation, 

Presently  under  development  is  the  interface  of  HULSTRX  and  SSDP,  The 
interface  program,  when  completed  in  early  1  9  8  3,  will  allow  most  longitu¬ 

dinal  structure  to  be  input  from  a  design  tool  to  a  graphic  tool  without 
a  great  deal  of  manual  interface,  The  engineer  still  makes  all  the 
engineering  decisions,  The  program  will  work  both  when  a  design  is 
near  completion  and  all  openings  or  holes  are  known,  as  well  as  from 
HULSTRX,  when  data  will  be  fed  to  SSDP  and  all  factors  of  safety  can  be 

checked,  Under  all  present  design  me  t  h  o  d  s ,  this  is  only  selectively 
done,  Planned  FY  83  developments  will  expand  the  use  of  the  program 
with  the  development  of  a  neutral  finite  element  file  from  HULSTRX  DGL, 
The  mesh  may  require  refinement  but  the  basic  structure  will  be  avail¬ 
able  in  a  format  that  will  allow  expansion  as  required- and  eliminate 
the  need  for  a  great  deal  of  mundane  development  work,  Another  inter¬ 

face  is  a  program  si  mi  I  ar  to  SSDP  that  will  do  commercial  design  hulls 
that  are  required  by  the  Navy,  The  need  to  interface  all  aspects  of 
conventional  shis  is  critical  as  ninety-five  (95)  percent  of  shipbuild¬ 
ing  dollars  are  in  this  area,  The  idea  of  making  a  program  that  will 

do  special  ships  in  all  materials  is  ideal  but  not  practical,  The 
unique  loading  and  materials  used  in  Hydrofoils,  LCAC,  SES,  and  Mine- 
hunters,  are  not  needed  in  a  standard  program, 


Ship  Structural  File  -  Program  Des  i  gn 


This  section  describes  the  design  considerations  and  their  i  mp I  e  me  n  t  a  - 

tion  in  the  making  of  the  interactive  Ship  Scantling  File  (SSF),  In 

addition,  s o me  general  thoughts  on  the  trend  that  is  being  p e r s u e d  in 
this  kind  of  work  are  outlined, 

The  SSF  is  essentially  a  file  containing  the  structural  data  that  can 

be  edited  interactively,  As  a  subsequent  step,  the  data  in  the  SSF 
will,  together  with  the  data  in  the  DGL  file,  be  used  for  the  generation 
of  structural  drawings  for  a  preliminary  and  contract  design, 

The  starting  point  for  the  SSF  is  an  existing  Design  Geometry  Library 
(DGL)  file,  A  separate  program  will  make  a  skeleton  SSF  based  on  the 

structural  members  in  the  DGL  file,  The  subsequent  editing  of  this  SSF 
is  accomplished  by  means  of  programming  that  enables  a  user  to  insert, 
mo  d  i  f  y  and  delete  data  for  structural  me  mb  e  r  s  represented  in  the  files, 
as  well  as  add  new  member s , 
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The  structural  parts  are  grouped  together  as  surfaces,  Some  of  the 
data  entered  into  the  file  applies  only  to  individual  surfaces;  s o me 
appl  y  to  whol  e  surfaces  as  such, 

Apart  from  the  programming  that  performs  the  editing  functions  there 
are  a  few  utility-type  functions  that  are  used  for  purposes  such  as 
starting  a  new  SSF,  packing  a  SSF,  creating  hard  copies  of  the  contents 
of  an  SSF,  creating  shapes  file  and  transfer  of  data  between  different 
types  of  computers, 

Program  Design 

The  major  considerations  that  governed  the  design  and  coding  effort  of 
this  programming  development  were: 

1,  Interactivity  and  user  friendliness,  Computer  programs  have  fre¬ 
quently  been  difficult  to  use,  Some  computer  experience  was  usually 
required  in  order  to  make  runs  for  the  purpose  of  performing  many 
engi  neeri  ng-type  calculations  by  means  of  a  computer  program,  The 
SSF  can  be  edited  by  personnel  without  any  computer  experience, 

It  has  also  been  designed  for  interactive  use  and  the  results  will 
be  right  there  for  the  user  to  see, 

The  editing  program  and  s  o  me  of  the  utility  p  r  o g  r  a  ms  are  c  o  mma  n d 
driven,  As  much  error  checking  as  possible  is  done  when  commands 
and  associated  data  are  keyed  in,  Unacceptable  commands  and  data 
are  flagged  i  mme  d  i  a  t  e  I  y  and  the  user  can  re-enter  the  proper  input, 
Help  functions  are  also  available,  Any  command  may  also  be 
terminated  by  simply  entering  a  $  in  the  command  string, 

2,  Program  transportability,  The  Navy  uses  a  number  of  different 
computers  and  conversion  problems  were  sought  avoided  to  the  great¬ 
est  extent  possible,  The  development  was  done  on  a  PRIME  computer 
and  then  put  up  on  a  VAX  11/780, 

The  ma c h i  n e - d e p e n d e n t  functions  such  as  reading  t i  me  and  date  from 
the  computer  system  as  well  as  some  file  accessing  were  isolated 
in  a  few  subroutines,  In  addition  the  initialization  of  logical 
unit  numbers  was  all  done  in  one  place,  As  a  result  of  this 

effort  the  conversion  to  the  VAX  was  accomplished  without  any 
difficulties, 

Another  aspect  of  t r ans por t abi  1 1 y  is  the  way  in  which  the  files 
used  during  a  run  are  opened  and  closed,  Both  PRIME  and  VAX  have 

a  Command  Processor  Language  which  handles  that  aspect  of  data 

management,  In  order  to  make  the  use  of  the  programs  as  easy  as 

possible,  the  files  could  have  been  opened  and  closed  from  within 
the  programs  during  the  run  time,  Such  an  arrangement  would, 

however,  have  required  machi  ne- dependent  FORTRAN  coding, 

3, '  Rapid  file  access,  This  aspect  is  really  an  extension  to  the  user 

friendliness  considerations,  as  sluggish  response  due  to  slow  file 
access  will  frustrate  users  and  make  the  program  less  acceptable, 
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Wi  t  h  this  r  e  q  u  i  r  e  me  n  t  in  mi  n  d  the  file  access  had  to  be  random 
rather  than  sequential,  However,  as  a  user  would  deal  with  one 

surface  at  a  time,  it  was  decided  to  lay  the  file  out  such  that  it 
would  be  searched  for  specific  items,  first  by  surface  and  then  by 
structural  component  within  the  surface,  This  arrangement  made 
the  programming  much  simpler  than  would  be  the  case  if  a  file 
organization  with  a  hashing  mechanism  for  placing  and  finding 
r  e  c  o  r  d  s  h  a  d  b  e  e  n  i  mp  I  e  me  n  t  e  d , 

4,  Since  a  number  of  structural  members  on  any  one  surface  will  be 
equal  with  respect  to  shape  and  size,  or  shape  only,  the  ability  to 
copy  data  from  one  member  onto  the  record  of  another  was 
considered  to  be  important,  Consequently,  data  already  entered 

for  one  member  or  for  a  whole  surface  can  be  transferred  with  ease 
to  another  me  mb  e  r  or  surface, 

5,  Structural  members  will  in  most  cases  be  cut  from  standard  shapes, 
There  are  presently  about  300  such  standard  shapes  available  from 
steel  mills  in  the  U.S,  A  file  with  such  shapes  has  therefore 
been  made,  together  with  the  necessary  programming  to  access  this 
file  so  that  the  user  only  need  specify  a  shape  number,  The 
abbreviated  description  of  the  shape  together  with  web  and  flange 
dimensions  will  be  fetched  out  of  this  shapes  file  and  stored  with 
t  h  e  s  t  r  u  c  t  u  r  a  I  me  mb  e  r , 

In  some  instances  special  shapes  or  built-up  members  will  have  to 
be  used,  The  file  with  standard  shapes  can  be  expanded  to 
accomodate  such  data  as  well  so  that  a  designer  will  have  as  easy 
access  to  such  data  as  he  has  to  data  describing  standard  steel 
mi  1 1  shapes, 

0,  Protection  of  data,  from  unauthorized  use  as  well  as  accidental 

destruction,  was  yet  another  concern,  The  data  files  can  therefore 
be  password  protected,  Whenever  opening  a  datafile  for  working 
the  user  will  be  asked  if  a  copy  of  the  file  to  be  edited  is  wanted 
so  that  if  a  run  is  terminated  improperly  only  that  work  done 
since  the  begi  nni  ng  of  the  run  wi  1 1  be  lost, 

In  fact,  whenever  writing  a  record  to  the  file,  new  or  updated, 
administrative  data  pertaining  to  the  surface  being  worked  on  as 
well  as  the  whole  file  as  such  is  updated,  The  chances  of  losing 
any  data  due  to  a  computer  crash  are  very  small,  If  the  option  to 
have  the  file  copied  at  the  beginning  of  the  run  is  exercised  very 
I i  1 1 1  e  woul  d  be  / os t , 

Ut  i  I  i  t  y  Functions 

A  number  of  Utility  functions  were  provided  with  this  programming  pack¬ 
age, 

The  starting  point  for  a  Ship  Scantling  File  is  an  existing  DGL  file  as 
generated  by  the  HULSTRX  program,  Such  a  file  contains  all  geometrical 
data  for  a  shi  p,  or  part  of  a  shi  p, 
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A  stand-alone  mainline  program,  S F N E W,  will  scan  a  DGL  file  and  create 
a  skeleton  DDF,  Every  surface  within  the  DGL  file  will  be  represented 
on  the  SSF  and  within  every  surface  all  structural  traces  will  be  rep¬ 

resented'  on  the  SSF,  A  trace  may  result  in  several  structural  pieces 
as  the  scantlings  ma y  change  along  a  longitudinal  or  a  f  r  a  me ,  The 
structural  traces  are  recognized  by  their  names,  On  a  DGL  file  there 

will  be  geometrical  information  that  does  not  represent  structures, 

Such  data  will  not  be  represented  in  the  SSF, 

Plates  will  also  be  represented  in  the  SSF,  In  a  sence  a  trace  can  be 
likened  to  a  plate  strake,  Such  a  strake  can  then  be  broken  down  into 
several  individual  plates, 

SFNEW  need  only  be  run  once  for  every  SSF  file,  It  generates  records 
for  all  surfaces  and  for  each  structural  trace  it  finds,  In  addition 
there  will  be  one  plate  record  for  each  surface,  No  specifics  as  regards 

structural  data  will  be  associated  with  the  surfaces  and  the  structural 

parts,  I  n  a  sense,  al I  records  wi  1 1  be  empty, 

By  initializing  an  SSF  this  way,  a  lot  of  work  is  saved  in  creating  the 
records,  This  process  lays  out  the  file,  Deletions  and  additions  can 
be  done  at  any  t  i  me  later  on, 

Once  a  SSF  has  been  established,  it  will  be  necessary  to  manage  it, 

The  functions  that  are  required  are  checking  of  password,  change  of  the 
password,  packing  the  file  and  producing  hard  copies  of  it,  The  program 
that  does  this  is  named  SFUTIL  and  is  command  driven  just  as  the  Editing 
program  itself,  Only  the  person,  or  persons,  that  are  authorized  to 
perform  file  ma n a g e me n t  functions  are  supposed  to  have  access  to  this 
program, 

The  library  of  standard  shapes  that  will  be  referenced  can  be  updated 
by  means  of  a  stand-alone  program  named  SHAPES.  The  main  function  of 
this  program  is  to  expand  the  file  of  standard  shapes  to  include  Special 
and  built  up  shapes,  It  is  also  to  be  used  for  the  purpose  of  mo  d  i  f  y  i  n  g 
or  removing  special  shapes,  SHAPES  is  command  driven,  just  as  SFNEW, 

It  is  not  expected  that  SHAPES  will  be  used  very  often, 

Apart  from  these  utility  functions,  there  are  two  additional  programs 
that  exist  for  the  purpose  of  moving  data  for  the  DGL  and  SHAPES  files 
between  two  computer  systems,  All  files  used  by  any  program  are  binary, 
i.e.  no  data  conversion  from  internal  representation  according  to  a 
FORMAT  statement  occurs  when  reading  from  a  file  or  the  other  way  around, 
when  writing  to  a  file,  Thereofore,  in  order  to  transfer  files  between 
computer  systems  the  binary  files  are  converted  to  data  in  ASCII  format, 
Files  on  the  system  from  which  the  transfer  is  to  take  place  will  be 
converted  from  binary  to  ASCII  and  then  transferred  via  tape,  On  the 
receiving  system  such  ASCII  files  will  be  converted  back  to  binary, 

The  program  that  converts  data  from  a  DGL  file  was  made  for  the  HULSTRX 
program  and  only  put  up  on  the  PRIME,  One  minor  modification  had  to  be 
made  inorder  to  make  this  program  work  on  both  PRIME  and  VAX  computers, 
This  pr ogr am  per f or  ms  the  conversions  both  ways,  i.e.  either  from 
ASCII  to  binary  or  the  other  way  around, 
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A  similar  program  was  made  for  the  purpose  of  transferring  data  for  the 
SHAPES, 


Editing  Program 
-  m  -  P  -  - 

The  main  editing  progran  is  named  SFEDIT,  It  is  programmed  in  FORTRAN 
and  makes  use  of  syst em  subrout i  nes  for  reading  time  and  date  as  well 
as  accessing  the  SSF,  The  reason  for  using  a  system  subroutine  for 

file  read  and  write  rather  than  standard  FORTRAN  random  access  read  and 
write  statements  is  that  processing  on  the  PRIME  is  much  faster  by 
using  the  sys t em  s ubr out i  ne,  However,  it  is  perfectly  possible  to  use 
the  FORTRAN  statements,  The  VAX  implementation  was  done  that  way,  It 
is  not  possible  to  use  both  access  methods  on  a  PRIME  file  as  there  is 
a  little  difference  in  the  way  the  data  is  laid  out, 

Two  concepts  need  be  explained  before  the  editing  functions  are  outlined: 

Current  The  record  or  records  being  worked  on  are  the  current  record 

or  records,  If  a  surface  as  such  is  being  worked  on,  supplying 

new,  replacing  existing  data  or  deleting  data,  then  the  surface 
is  current,  All  functions  relate  to  the  surface,  If  the  sur¬ 

face  is  deleted,  i ,  e ,  r e mo v e d  from  the  file,  then  all  records 
for  plates  or  structural  pieces  belonging  to  the  surface  as 
well  the  surface  record  is  removed, 

When  a  plate  or  structural  part  is  current,  then  both  the 

surface  and  the  plate  or  piece  are  current,  However,  when 
such  a  plate  or  piece  is  r e mo v e d  the  surface  and  all  other 
plates  and  pieces  under  it  r  emai  n  as  is, 

Active  Data  describing  the  surface  and  its  individual  plates  or 

)  i e c  e s  are  entered  by  me  a  n s  of  s  o  me  of  the  c  o  mma  n d s  described 
)  e  I  o  w  and  placed  in  a  buffer,  The  data  in  this  buffer  is 
referred  to  as  the  active  data,  Whenever  a  record  is  filed 
or  stored  data  from  the  active  buffer  is  written  out  to  the 
record  on  the  file, 

The  active  buffer  may  contain  data  pertaining  to  a  surface, 
to  a  plate  and  to  a  structural  piece,  During  the  filing 
operation  only  that  which  pertains  to  the  type  of  record  is 
written  to  the  record  on  the  file, 

The  editing  functions  that  are  provided  in  the  editing  p  r  o  g  r  a  ms  are 
these: 

BOUND  Prompts  for  bounding  data  for  a  surface  or  plate  or 

st  r  uct  ur  al  pi  ece, 

CLEAR  Clears  all  data  from  the  active  buffer, 

DELETE  Deletes  the  current  surface  with  all  associated  plate  or 

structural  pieces  or  individual  pieces  only, 
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END  Ter  mi  nat  es  the  editing  session, 

F  I  L  E  Wr  i  t  e s  active  data  on  current  record, 

GET  Reads  specified  record  from  the  SSF, 

I  DNAME  Lists  standard  6-character  identifiers, 

INTERSECT  Prompts  for  intersection  data  for  the  current  surface, 

LIST  Provides  listing  of  specified  type  of  records  which  may  include 

all  surfaces  in  the  file  or  all  plates  or  structural  pieces 
wi  t  hi  n  t  he  c ur  r  ent  s ur  f  ace, 

MATERIAL  Prompts  for  the  material  type, 

NEXT  Displays  next  logical  record  on  SSF, 

ORI  ENT  Used  t  o  def i  ne  or i  ent  at i  on, 

PI  ECE  Fi  nds  and  di  spl  ays  specified  piece, 

PLATE  Finds  and  displays  specified  plate, 

SCANTLING  Prompts  for  plate/shape  scantling, 

SET  Makes  parameters  of  current  SSF  record  active,  i.e.  moves 

data  from  file  record  to  active  buffer, 

SHAPE  Finds  and  displays  specified  shape, 

STATUS  Displays  non-zero  active  data  for  the  kind  of  record  being 

current , 

SURFACE  Finds  and  displays  specified  surface, 

All  the  commands  can  be  abbreviated  to  the  first  two  letters,  i.e.  FI 
for  FILE,  MA  for  MATERIAL,  PI  for  piece,  etc, 

Most  of  the  commands  will  read  the  associated  data  from  the  same  line 
as  the  command  and  will  prompt  the  user  for  that  which  is  not  found, 

Some  commands  will  prompt  for  individual  data  as  it  would  not  all  fit 
on  one  line, 

There  is  also  a  HELP  function  which  will  list  all  the  commands  with  a 

brief  description  of  what  they  do,  If  a  command  is  not  recognized  the 
user  will  be  given  -a  message  to  that  effect, 

All  data  read  will  be  interpreted  by  the  program  rather  than  a  FORTRAN 

FORMAT  statement  which  may  cause  program  termination  if  the  data  is 

mistyped,  By  having  it  this  way,  errors  made  in  typing  can  be  corrected 

by  retyping, 
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Future  Data  Base  Design  -  Considerations 


This  section  outlines  the  r  e q u i  r  e me n t  s  of  a  future  data  base  based  on 
the  present  experi  ences, 

The  present  state  of  the  p  r  o  g  r  a  ms  used  in  ship  design  and  manufacturi  ng 

in  the  U.S.  and  indeed  around  the  world  is  that  interactivity  such  as 
is  now  possible  with  multi-user  operating  systems  on  very  reasonable 
mi  ni  -  comput  er  s  is  not  fully  taken  advantage  of,  A  number  of  programs 
that  where  written  in  the  days  of  cards  and  batch  processing  are  still 
around, 

Special  interfaces  have  been  and  are  being  made  to  allow  output  from 

one  program  to  be  used  as  input  to  another,  Many  existing  programs 
are  difficult  to  use  due  to  input  requirements  designed  for  cards  with 

little  or  no  concern  for  other  uses,  or  for  how  the  input  could  be  made 

flexible,  Another  way  of  expressing  this  would  be  to  call  it  user 
unfriendly, 

Transfer  of  data  between  different  types  of  computer  equipment  is  fre¬ 
quently  less  easy  than  it  is  possible  to  make  it,  This  applies  in 

particular  to  systems  with  reasonably  sophisticated  data  base  designs, 

In  particular,  it  is  not  possible  to  down- load  portions  of  a  data  base 

to  a  smaller  computer  over  a  dial-up  communication  link  for  off  line 

work  and  then  to  transfer  the  results  of  such  work  to  a  larger  data  base 

over  the  s  a  me  dial  up  c  o  mmu  n  i  c  a  t  i  o  n  link  at  a  later  stage, 

Another  aspect  of  present  day  software  technology  is  that  some  programs 

have  to  access  different  data  files  in  different  ways  in  order  to  get 

at  all  the  data  that  is  needed  for  a  specific  application, 

Significant  improvements  in  the  ease  of  use  of  programs  can  be  made  with 
a  relatively  small  effort  towards  making  existing  programs  truly  inter¬ 
active  and  in  designing  data  base  systems  that  will  enable  transfer  of 
data  between  different  application  programs  and  between  different  com¬ 
puter  e  q  u  i  p  me  n  t ,  The  rest  of  this  section  is  devoted  to  s  o  me  of  the 

design  r  e q u i  r  e me n t  s  of  such  a  data  base, 

The  main  requirements  of  such  a  data  base  are  as  follows: 

Files  Sequential  files  are  so  slow  to  access  in  any  other  way 

than  record  by  record  as  they  occur  that  the  only  accept¬ 
able  way  is  random  access,  Such  an  access  will  in  most 

instances  require  a  hashing  me  c  h  a  n  i  s  m,  although  it  is 
possible  to  design  access  methods  that  will  use  data  from 
a  previous  record  to  calculate  the  position  of  the  next 
one  t  o  be  ex  a  mi  ned, 
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Records 


Access 


A  hashing  mechanism  imposes  a  software  overhead  and  will 
require  mo  r  e  physical  disk  space  than  a  sequential  file 
due  to  the  fact  that  some  record  spaces  will  not  be  filled, 

However,  it  is  the  best  way  to  find  where  to  put  a  record 
and  where  to  find  it  again  later  in  as  short  a  time  as 
possible,  The  response  from  the  system  is  e  x  t  r  e  me  I  y 
important  when  a  file  is  being  accessed  interactively, 

There  are  other  ways  of  placing  records  in  a  direct  access 

file  than  hashing,  but  the  programming  overheads  are 
usually  as  large  and  the  response  would  be  slower  because 
it  would  involve  some  searching  in  a  register, 

The  records  to  be  used  must  necessarily  be  of  varying 
length  and  they  must  not  be  laid  out  in  just  one  fixed 

way,  It  is  possible  to  store  one  or  a  couple  of  keys 
with  the  record  that  can  be  used  to  indicate  both  lay-out 

and  I  engt  h, 

The  requirement  of  having  records  of  varying  lengths 
makes  it  necessary  to  have  an  index  area  which  must  remain 
in  the  file  at  all  times,  Each  record  will  have  its  name 
entered  here  together  with  information  such  as  time/ date 
stamp  and  pointers  to  where  the  record  data  is  stored, 

As  records  are  entered,  the  file  will  grow,  Since  the 
records  are  to  be  of  varying  lengths,  they  must  consist 
of  a  number  of  blocks,  each  of  standard  length,  A  record 
will  therefore  consist  of  one  or  more  such  blocks  apart 
f  r  om  t  he  entry  in  the  file  register, 

The  position  of  a  record  in  the  register  will  be  determined 
by  a  hashing  mechanism,  If  all  records  were  to  be  of  one 
size,  then  the  file  could  be  initialized  with  a  number  of 
such  record,  The  n  a  me ,  d  a  t  e  / 1  i  me  s  t  a  mp  and  other  a  d  mi  n i  s  - 
trative  data  could  reside  in  the  record  together  with  the 
actual  record  data, 

There  are  two  aspects  of  access,  It  should  be  easy  to 
store  and  retrieve  data  in  the  files  for  just  about  any 
program  and  it  should  be  possible  to  transfer  records 
between  computer  systems  over  dial-up  communication  lines, 

In  particular,  it  will  become  important  to  be  able  to 
down- load  only  a  part  of  a  data  base  to  a  smaller  stand 
alone  computer  and  then  to  up- load  the  result  of  work 
done  on  such  a  system  to  the  host  computer, 

There  are  far  too  ma  n  y  p  r  o  g  r  a  ms  today  that  still  operate 
independently  of  related  programs,  Programs  written  for 
the  c o mp u t  e r  e q u i  p me n t  of  yesterday  have  been  converted 
to  read  from  a  file  rather  than  a  card  reader  and  to 
write  to  a  file  instead  of  a  line  printer,  Such  programs 
were  made  with  little  or  no  concern  for  other  uses  of  the 
output,  Some  were  made  to  produce  a  deck  of  cards,  or  a 
file  that  could  be  used  by  other  p r  o g r  a  ms , 
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The  more  advanced  systems  such  as  CAD/CAM  programs  were 
made  with  highly  specialized  data  bases  that  were  diffi¬ 
cult,  if  not  impossible,  to  access  for  uses  other  than 
those  associated  with  the  system  for  which  it  was  made, 

Interactivity  In  going  from  batch  oriented  p  r  o  g  r  a  mmi  n  g  s  y  s  t  e  ms  to  inter¬ 
active  systems,  the  old  databases  were  frequently  retained 
or  slightly  mo  d  i  f  i  e  d ,  The  t  i  me  in  accessing  such  data 
bases  frequently  were  too  large  for  the  system  to  be 
accepted  by  users,  Rapid  response  from  an  interactive 
system  will  depend  on  the  data  base  design  as  far  as 
retrieval  of  data  is  concerned,  Sluggishness  in  such 
responses  will  make  a  system  less  acceptable, 

The  second  aspect  of  interactivity  is  the  way  in  which  a 
system  lets  users  enter  data,  This  has  no  direct  bearing 
on  the  data  base  design,  but  deserves  a  few  words  in  this 
context,  Well  designed  screen  layouts  with  prompts  can 
be  very  helpful,  Error  checking  at  the  earliest  possible 
stage  is  also  important  in  that  it  lets  the  user  recover 
as  early  and  as  often  as  possible, 


Sharing  Data  Down-loading  parts  of  a  data  base  to  a  stand-alone  system 
will  become  more  desirable  as  the  hosts  themselves  become 
smaller  and  smaller,  A  number  of  functions  can  be  per¬ 
formed  by  stand  alone  micros  which  can  qo  in  and  fetch 
data  for  a  day's  work,  At  the  end  of  trie  day  the  result 

can  be  put  back  into  the  databank  in  the  host,  Over  a 
dial-up  line,  independent  work  stations  can  be  set  up  in 
a  different  location  and  reduce  the  demand  on  CPU  in  a 
central  computer,  At  the  end  of  a  task  the  result  can 
then  be  t  r  a  ns  mi  1 1  ed  back  to  the  host , 

The  result  of  work  in  an  independant  workstation  may 
result  i  n -  a d d i t i o n a  I  records  or  mo d i f i c  a  t  i  o n  of  those 
that  were  down-loaded,  The  modified  ones  will  replace 

the  original  ones  when  the  result  is  sent  back  into  the 
host  computer, 

Another  reason  for  communications  is  that  a  data  bank  or 
part  of  one  may  be  transferred  between  computers,  thus 
avoiding  delays  associated  with  sending  tapes  or  floppy 
disks  through  the  mai  I , 

The  communication  interface  at  a  host  computer  can  be 
written  as  an  extension  to  the  data  base  programming,  It 
will  be  required  to  fetch  a  specified  record  from  a  file, 
possibly  do  some  conversions  and  then  transmit  bytes  down 
the  line,  The  records  moved  that  way  will  be  put  into  a 
data  base  in  the  receiving  system,  The  specific  file 
into  which  they  will  go  need  not  be  the  same  size  as  that 
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Portability 


Data  Safety 


Secur i  t  y 


in  the  sending  system,  When  a  record  is  entered  into  any 
such  system,  its  n  a  me  is  hashed  and  the  result  of  that 
hashing  will  be  a  fraction  as  well  as  a  specific  number 
for  the  file  into  which  it  is  to  go  first,  For  subsequent 
transfers,  the  fraction  will  be  used  to  determine  the 
place  in  any  dat  a  base, 

The  software  needed  to  implement  a  scheme  such  as  has 
been  outlined  above  needs  to  be  portable  if  it  is  to  be 
implemented  on  several  types  of  computers,  Efficiency 
will,  however,  demand  that  some  parts  will  be  accomplished 
by  me  a  n s  of  system  subroutines  already  available  for  s  o  me 
s  y  s  t  e  ms  or  by  a  s  s  e  mb  I  y  on  others,  The  i  mp  o  r  t  a  n  t  portabil¬ 
ity  aspect  here  is  well-defined  specifications  so  that 
certain  pieces  of  software  such  as  file  handling,  file 
access  input  routines  and  communications  can  be  implemented 
on  a  number  of  different  types  of  computers  --  micros, 
s uper  -  mi  c r  os ,  mi  ni  s  and  mai  nf  r  ames , 

A  data  base  system  to  be  put  in  place  on  several  physical 
computers  and  linking  these  by  telephone  lines  must  neces¬ 
sarily  have  built-in  safe  guards  against  the  loss  of  data 
whenever  a  run  is  terminated  improperly  due  to  a  line 
being  lost,  There  are  several  design  features  that  can 
be  built  in  to  mi  n  i  mi  z  e  the  loss  and  to  ma  k  e  recovery  as 
painless  as  possible,  Just  to  indicate  the  kind  of  fea¬ 
tures  that  mi  g  h  t  be  designed  in  it  can  be  me  n  t  i  o  n  e  d  that 
a  continual  updating  of  all  administrative  data  on  the 
physical  disk  file  will  minimize  the  loss,  A  recovery 
can  be  made  fairly  easy  by  keeping  one  record  that  at  all 
t  i  me  s  indicates  the  very  last  record  put  in  place  and 
s  o  me  d  a  t  a  r  e  g  a  r  d  i  n  g  i  t , 

By  making  a  data  base  accessible  from  several  locations 
it  will  be  necessary  to  provide  some  security  in  the  form 
of  passwords  and  scrambling,  These  measures  are  meant 
only  to  make  it  difficult  to  access  data  that  should  not 
be  available  to  just  anybody.  They  are  not  meant  to 
protect  classified  data,  However,  passwords  and  scramb- 
i ng  can  be  a  considerable  deterrent  to  anyone  attempting 
to  see  what  ki  nd  of  dat  a  i  s  i  n  a  f i I  e, 
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INTERACTIVE 
EDITING  OF 
SSF 


GRAPHIC 
DISPLAY  OF 
SSF 


Figure  2  ■  Gr a ph i  c  Display  of  SSF 


SSF  PROGRAM  DESIGN  CONSIDERATION 

i  I  NTERACTI  VI TY 
i  PORTABI  LI  TY 

•  RAPI  D  FILE  ACCESS 

•  EASY  FILE  EXPANSI  ON 

•  PROTECTION  OF  DATA 
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SSF  UTILITY  FUNCTIONS 


i  CRE ATI  ON  OF  SKELETON  FILE 
i  CRE ATI  ON  OF  STANDARD  SHAPES  FILE 
i  PASSWORD  CHANGES 
i  PACKI  NG 

i  TRANSFER  OF  DATA  BETWEEN  COMPUTER  SYSTEMS 


SSF  EDITING  F  UNCTI  ON/  DE  F I  Nl  NG  STRUCTURES 

•BOUNDING  STRUCTURES  AND  SURFACES 

•  DEFINING  SCANTLI  NGS  OF  SHAPES 

•  DEFINING  PLATE  THI  CKNESS  OF  PLATES 

•  DEFINING  MATERIAL 

•  ORIENTATION 

•  DEFINING  SURFACE  INTERSECTION 
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SSF  EDITING  FUNCTI  ONS/ SEARCHI  NG 


•  FI  NDS  ANY  MEMBER  ON  FILE 

.  FI  NDS  NEXT  PLATE.  OR-  PI  ECE 

•  FI  NDS  SURFACE 

•  FI  NDS  SPECI  FI  ED  SHAPE  Wl  THI  N  SURFACE 

I 

•  FI  NDS  SPECIFIED  PIECE  Wl  THI  N  SURFACE 

I 

•  FI  NDS  SPECIFIED  PLATE  Wl  THI  N  SURFACE 

ANY  SURFACE,  PLATE  OR  PIECE  NOT  FOUND  RESULTS 
I  N  CREATI ON  OF  NEW  I  TEM 


ssf  EDITING  FUNCTI  ON/ DATA  MOVEMENTS 

SETS  ACTIVE  BUFFER  EQUAL  TO  SCANTLINGS  FOR  SURFACE, 
PLATE  OR  PI  ECE 

FILES  SCANTLING  RECORD,  SURFACE  PLATE  OR  PIECE 
•  delete  SCANTLING  RECORD  FOR  SURFACE  plate  OR  Piece 
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REQUIREMENTS  FOR  FUTURE  DATA  BASE 


•  RAPI  D  FILE  ACCESS 

•RECORD  LENGTHS  OF  VARYING  LENGTHS 

•  Dl  AL  UP  ACCESS 

•  *  E AS Y  ACCESS  FOR  ANY  PROGRAM 

•  I  NTERACTI  VI  TY 

•SHARING  DATA  BETWEEN  COMPUTERS 

•  PORTABI  LI  TY 

•  DATA  SAFETY 

•  DATA  SECURI  TY 
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